10. AI协议生态与互操作

版本：v1.0
最后更新：2026-07-07
适用对象：想理解 MCP、A2A、ACP、AG-UI、Function Calling、Structured Outputs、Realtime 等 AI 协议如何分工与落地的学习者

1. 为什么需要专门学习 AI 协议

早期 AI 应用通常只有一条链路：

text

用户输入 -> 调模型 API -> 返回文本

但 Agent 和企业级 AI 应用出现后，链路变成了：

text

用户界面
  -> Agent 运行时
  -> 模型
  -> 工具 / 数据 / 工作流
  -> 其他 Agent
  -> 审批 / 审计 / 观测系统

这时，如果每个系统都自己定义一套消息格式、工具格式、鉴权方式、状态更新方式，就会出现几个问题：

工具接入无法复用
Agent 之间不能互相委托任务
前端无法稳定展示 Agent 中间状态
长任务、流式任务、取消、重试、审批都靠临时约定
不同框架、不同供应商之间迁移成本很高

AI 协议的价值，就是把这些交互边界标准化。

一句话理解：

协议不是模型能力本身，而是模型、Agent、工具、数据、前端和其他系统之间的协作契约

2. AI 协议地图

不要把所有 AI 协议混在一起看。它们解决的是不同层的问题。

层级	典型协议 / 能力	解决的问题	典型场景
模型输出层	Structured Outputs、JSON Schema	模型输出是否稳定可解析	分类、抽取、审批结果、评分结果
模型工具层	Function Calling、Tool Calling	模型如何请求应用执行函数	查订单、查库存、发工单、搜索
Agent 工具与上下文层	MCP	Agent 如何标准化连接外部工具、资源、Prompt	文件、数据库、搜索、企业系统
Agent 协作层	A2A、ACP	Agent 如何发现、委托、协作、返回任务结果	多团队 Agent、跨组织 Agent、专家 Agent 网络
Agent 前端交互层	AG-UI	Agent 如何把状态、事件、UI 意图同步给前端	Copilot、工作台、可中断长任务
实时交互层	Realtime API、WebRTC、WebSocket、SIP	语音、音频、低延迟流式交互	语音客服、实时翻译、会议助手
传统服务接口层	REST、OpenAPI、GraphQL、gRPC	业务系统如何暴露能力	CRM、ERP、工单、支付、权限系统

最重要的结论：

MCP、A2A、AG-UI 不是互相替代关系。
它们更像三条不同方向的连接线。
Function Calling 和 Structured Outputs 更靠近模型 API 层。
REST / OpenAPI / GraphQL / gRPC 仍然是企业系统的底层服务接口。

3. 一张图理解 MCP、A2A、AG-UI

text

                    用户 / 前端应用
                         |
                         | AG-UI
                         v
                  Agent Runtime
                   /        \
                  /          \
              MCP             A2A
                |              |
                v              v
          工具 / 数据源      其他 Agent

这个图可以这样读：

AG-UI 解决前端和 Agent 后端之间如何交换事件、状态、用户意图。
MCP 解决 Agent 如何连接工具、数据源、资源和预定义 Prompt。
A2A 解决一个 Agent 如何发现、调用、委托另一个 Agent。

如果你只记一句话：

AG-UI 面向用户交互，MCP 面向工具和数据，A2A 面向 Agent 协作

4. MCP：Agent 到工具与数据的协议

MCP 全称是 Model Context Protocol。

根据 MCP 官方文档在 2026-07-07 可访问的说明，MCP 是一个开源标准，用来把 AI 应用连接到外部系统，包括数据源、工具和工作流。官方文档也把它类比为 AI 应用的 USB-C 接口。

4.1 MCP 解决什么问题

没有 MCP 时，常见做法是：

text

Agent A 自己定义 GitHub 工具
Agent B 自己定义 GitHub 工具
Agent C 自己定义 GitHub 工具

问题是：

工具 schema 不统一
鉴权方式不统一
错误处理不统一
审批和审计不统一
换一个 Agent 宿主就要重新接一遍

有 MCP 后，可以变成：

text

GitHub MCP Server
  -> 暴露 tools / resources / prompts
  -> 多个 MCP Client 或 AI 应用复用

4.2 MCP 的核心角色

MCP 规格里有三个核心角色：

角色	含义
Host	发起连接的 LLM 应用，例如 IDE、聊天应用、Agent 平台
Client	Host 内部的连接器，负责与 MCP Server 通信
Server	提供工具、资源、Prompt 的服务

这和很多人一开始理解的“模型直接调工具”不一样。

更准确的链路是：

text

模型提出工具意图
  -> Host / Client 判断是否允许
  -> MCP Server 执行或返回资源
  -> 结果回传给模型

4.3 MCP 的核心能力

MCP Server 可以向 Client 提供：

能力	作用	示例
tools	可执行函数	搜索、查库、创建工单、运行脚本
resources	可读取上下文	文件、文档、表结构、配置
prompts	预定义交互模板	代码审查 Prompt、排障 Prompt

MCP Client 也可以向 Server 提供一些能力，例如 sampling、roots、elicitation 等。

从学习角度，先把 tools、resources、prompts 三个概念掌握住就够了。

4.4 MCP 适合什么时候用

适合：

一个工具要给多个 Agent 或多个客户端复用
企业内部有多种数据源和系统要接入
需要把工具、资源、Prompt 按统一协议暴露
需要明确用户授权、审批和审计
未来可能接入 Claude、ChatGPT、IDE、内部 Agent 平台等多个宿主

不一定适合：

一次性 Demo
只有一个本地函数的小项目
没有复用诉求的临时脚本
对外部系统没有访问需求的纯文本任务

4.5 MCP 的安全要点

MCP 官方规格强调了用户同意、数据隐私、工具安全和采样控制。

落地时建议至少做到：

工具调用前能让用户知道将执行什么
高风险工具默认需要审批
Server 不应看到不必要的用户数据
Host 要限制 Server 可访问的资源边界
工具描述也要视为不可信输入，不能盲目信任
工具调用、参数、结果和审批记录要进入审计日志

MCP 不是安全机制本身，它只是协议边界。真正的安全还要靠权限、审批、隔离、审计和回滚。

5. Function Calling：模型到应用函数的协议

Function Calling 也常被称为 Tool Calling。

根据 OpenAI 官方文档在 2026-07-07 可访问的说明，Function Calling 让模型能够与外部系统交互，访问训练数据之外的信息，或请求应用执行动作。

5.1 Function Calling 的基本流程

text

应用定义工具 schema
  -> 请求模型时带上可用工具列表
  -> 模型判断是否需要工具
  -> 模型返回 tool call 和参数
  -> 应用执行真实函数
  -> 应用把执行结果返回给模型
  -> 模型生成最终回答

注意：

模型不会真的执行函数。
真正执行的是你的应用或运行时。
所以应用必须做参数校验、权限判断、审批和错误处理。

5.2 Function Calling 和 MCP 的区别

对比项	Function Calling	MCP
主要定位	单个模型调用应用定义的函数	标准化连接外部工具、资源和 Prompt
接入范围	通常在某个模型 API 或应用内部	可被多个 Host / Client 复用
抽象层级	模型 API 能力	Agent 工具与上下文协议
适合场景	应用内函数少、链路简单	工具多、客户端多、需要生态复用

一个实用判断：

项目早期可以先用 Function Calling。
工具变多、复用变强、跨客户端接入时再抽成 MCP Server。

5.3 工具 schema 的设计原则

好的工具 schema 要满足：

工具名像动词，不要太泛
参数少而明确
必填和可选字段分清
枚举值固定
返回结构稳定
错误信息可操作
读写工具分离
高风险工具显式标注风险

差工具：

text

process(data, options)

好工具：

text

get_order_status(order_id)
create_refund_request(order_id, reason, amount)

6. Structured Outputs：模型输出结构协议

不是所有结构化需求都应该做成工具调用。

如果你只是希望模型返回一个稳定结构，例如：

分类结果
审批结果
提取字段
风险评分
页面配置

更适合使用 Structured Outputs 或 JSON Schema。

根据 OpenAI 官方 Structured Outputs 文档在 2026-07-07 可访问的说明，Structured Outputs 可以确保模型输出遵守你提供的 JSON Schema，避免缺必填字段或返回非法枚举。

6.1 Structured Outputs 和 Function Calling 怎么选

需求	推荐方式
模型要调用外部函数	Function Calling
模型要返回可解析 JSON	Structured Outputs
模型要调用工具并保证工具参数合法	Function Calling + strict schema
模型要给前端生成结构化展示数据	Structured Outputs
模型要读取企业系统数据	Function Calling 或 MCP

简单记法：

要执行动作，用 Function Calling
要稳定返回结构，用 Structured Outputs
要标准化暴露工具和资源，用 MCP

6.2 JSON Schema 设计建议

建议：

字段不要过多
关键状态用 enum
缺失信息用 null、unknown、missing_fields 明确表达
高风险判断要带 evidence
不要把错误塞进正常字段
需要人工介入时用 need_human_review

示例：

json

{
  "decision": "approve | reject | need_more_info",
  "risk_level": "low | medium | high",
  "confidence": 0.82,
  "evidence": ["原文证据片段"],
  "missing_fields": [],
  "need_human_review": false
}

7. A2A：Agent 到 Agent 的协议

A2A 全称是 Agent2Agent Protocol。

根据 A2A 官方文档在 2026-07-07 可访问的说明，A2A 是一个开放标准，用于 AI Agent 之间的通信和协作。它强调不同框架、不同供应商构建的 Agent 可以通过共同语言互操作。

7.1 A2A 解决什么问题

当系统变复杂后，你可能会有多个专门 Agent：

客服 Agent
账单 Agent
代码 Agent
数据分析 Agent
审批 Agent
运维 Agent

如果每个 Agent 之间都靠自定义 HTTP 接口互调，很快会变成网状复杂度：

text

Agent A -> Agent B 自定义接口
Agent A -> Agent C 自定义接口
Agent B -> Agent D 自定义接口
Agent C -> Agent D 自定义接口

A2A 试图把这个边界标准化：

text

Client Agent
  -> 发现 Remote Agent
  -> 发送任务
  -> 订阅状态
  -> 接收结果或工件

7.2 A2A 的核心概念

从学习角度先掌握这些：

概念	含义
Agent Card	Agent 的能力说明和发现元数据
Task	一次可跟踪的任务
Message	Agent 间交换的消息
Artifact	任务产物，例如文件、报告、结构化结果
Streaming	长任务过程中的状态更新
Push Notification	异步任务完成后的通知机制

A2A 的重点不是“怎么写一个 Agent”，而是“不同 Agent 怎么互相发现、委托和协作”。

7.3 A2A 和 MCP 的关系

A2A 官方文档明确强调：A2A 和 MCP 不是竞争关系，而是互补关系。

协议	连接方向
MCP	Agent -> 工具 / 数据 / 资源
A2A	Agent -> Agent

举例：

text

销售 Agent
  -> 通过 A2A 委托 财务 Agent 判断账单
  -> 财务 Agent 通过 MCP 查询发票系统
  -> 财务 Agent 把结果通过 A2A 返回

7.4 A2A 不是什么

A2A 不是：

Agent 开发框架
工具调用协议
MCP 替代品
聊天软件协议
内部子 Agent 调用的唯一方式

它的定位更窄也更清楚：跨 Agent 通信与互操作。

8. ACP：Agent Communication Protocol

ACP 全称是 Agent Communication Protocol。

根据 ACP 官方文档在 2026-07-07 可访问的说明，ACP 是一个用于 Agent 互操作的开放协议，支持 RESTful API、同步/异步通信、流式交互、状态型与无状态模式、Agent 发现和长任务。

同时，ACP 官方文档也明确提示：ACP 现在已经成为 Linux Foundation 下 A2A 的一部分。

8.1 ACP 的特点

ACP 的设计特点包括：

基于 REST，容易接入现有工程系统
支持多模态消息
支持同步和异步
支持流式交互
支持在线与离线 Agent 发现
支持长任务
可以不依赖 SDK，直接用 HTTP 工具调用

8.2 ACP 和 A2A 怎么理解

从学习和选型角度可以这样看：

如果你看到 ACP 资料，不要忽略，它解释了很多 Agent 通信设计问题。
但做新项目时，应优先关注 A2A 官方路线和最新规范。
ACP 的 REST 思路对企业内部集成仍然很有参考价值。

8.3 企业里什么时候会关注 ACP

可能场景：

团队已有 REST API 网关和 OpenAPI 治理体系
想把 Agent 包装成可发现、可调用的标准服务
需要异步任务、长任务、流式输出和多模态消息
希望 Agent 可以被替换，而调用方不需要改很多代码

9. AG-UI：Agent 到用户界面的协议

AG-UI 全称是 Agent User Interaction Protocol。

根据 AG-UI 官方文档在 2026-07-07 可访问的说明，AG-UI 是一个开放、轻量、基于事件的协议，用来标准化 AI Agent 如何连接用户侧应用。它关注的是 Agent 状态、UI 意图、用户交互如何在 Agent 后端和前端应用之间流动。

9.1 为什么传统 REST 不够

传统 Web 应用经常是：

text

前端请求 -> 后端返回 -> 前端渲染

Agent 应用更像：

text

前端发起任务
  -> Agent 流式返回状态
  -> Agent 请求用户确认
  -> 前端展示工具结果
  -> 用户中断或修改
  -> Agent 继续执行
  -> 前端渲染最终结果

这需要表达：

token 流
状态变更
工具调用进度
人工审批
中断和恢复
UI 组件生成
多模态附件
前端执行动作

这些都不是普通一次性 HTTP 响应能很好表达的。

9.2 AG-UI 适合什么场景

适合：

AI Copilot 工作台
可中断长任务
需要展示 Agent 中间状态
需要用户审批、编辑、重试、接管
前端要渲染工具结果和任务进度
Agent 要和 Web / Mobile / 桌面端互动

不一定需要：

纯后端批处理任务
没有前端交互的定时任务
一问一答且无工具调用的聊天

9.3 AG-UI 和 A2A、MCP 的关系

AG-UI 官方文档也把三类协议放在不同层：

连接方向	协议
Agent <-> User Interaction	AG-UI
Agent <-> Tools & Data	MCP
Agent <-> Agent	A2A

所以如果你在做一个完整 Agent 产品，可能三者都会出现：

text

前端工作台 -- AG-UI --> 客服 Agent
客服 Agent -- MCP --> 工单系统 / 知识库 / CRM
客服 Agent -- A2A --> 财务 Agent / 风控 Agent

10. Realtime：实时语音和低延迟交互协议

实时语音 Agent 还会涉及另一类协议：低延迟音频、事件和会话状态。

以 OpenAI Realtime API 为例，官方文档在 2026-07-07 可访问的说明中提到，语音 Agent 会连接 /v1/realtime，发送音频或文本，并监听模型响应、工具调用和 session events。

10.1 连接方式怎么选

常见选择：

方式	适合场景
WebRTC	浏览器或移动端直接采集和播放音频
WebSocket	服务端已有音频管线、呼叫系统或 worker
SIP	电话系统、呼叫中心、语音坐席

10.2 Realtime 和其他协议怎么配合

实时语音不是孤立的。

它可能同时需要：

Function Calling：语音过程中查订单、改预约
MCP：接企业知识库、CRM、工单系统
AG-UI：在客服工作台展示实时转写和工具状态
A2A：把复杂问题委托给专家 Agent

实时链路的难点通常不是“能不能说话”，而是：

低延迟
打断处理
语音活动检测
工具调用期间的等待体验
会话状态同步
安全身份标识
成本和并发控制

11. OpenAPI、REST、GraphQL、gRPC 仍然重要

AI 协议不是要替代传统 API。

企业内部大多数真实能力仍然由传统服务接口提供：

订单系统
支付系统
账号系统
权限系统
库存系统
工单系统
数据平台

AI 层通常只是把这些能力包装成更适合模型或 Agent 使用的接口。

11.1 一个推荐分层

text

业务系统 REST / GraphQL / gRPC / SQL
  -> 服务适配层
  -> Tool Schema / MCP Server
  -> Agent Runtime
  -> AG-UI / A2A / Realtime
  -> 用户或其他 Agent

不要让模型直接面对复杂的原始业务 API。

更稳的做法是：

先把业务 API 包装成少量清晰工具
读写分离
高风险动作单独建工具
工具输出做标准化
错误码转成人和模型都能理解的信息

11.2 OpenAPI 和 AI 工具的关系

OpenAPI 可以帮助描述传统 REST API，但它通常还不等于一个好工具。

原因是：

业务 API 往往参数太多
API 命名面向研发，不面向模型
一个 API 可能混合读写副作用
错误信息可能不适合模型恢复
权限和审批不一定适配 Agent 风险

所以从 OpenAPI 到工具层，通常需要再做一次 Agent 友好设计。

12. 企业 AI 协议选型建议

12.1 从简单到复杂的路线

建议按这个顺序演进：

先用 Structured Outputs 稳定输出。
再用 Function Calling 接少量本地工具。
工具变多后抽成 MCP Server。
需要多 Agent 跨系统协作时引入 A2A。
需要复杂前端交互时引入 AG-UI。
需要语音或低延迟多模态时引入 Realtime / WebRTC / WebSocket。

不要一开始就把所有协议都上齐。

12.2 按场景选择

场景	优先考虑
分类、抽取、审批结果	Structured Outputs
单应用内查订单、发工单	Function Calling
多客户端复用企业工具	MCP
多 Agent 跨框架协作	A2A
Agent 工作台、Copilot UI	AG-UI
语音客服、实时翻译	Realtime + WebRTC / WebSocket / SIP
传统业务系统接入	OpenAPI / REST / GraphQL / gRPC + 工具适配层

12.3 选型时最该问的问题

是模型输出格式问题，还是外部能力接入问题？
是单应用内调用，还是要跨客户端复用？
是 Agent 调工具，还是 Agent 调 Agent？
是否需要用户在执行中确认、中断、修改？
是否有长任务、异步、流式、取消和恢复？
是否需要多租户、权限、审计、审批？
是否要支持多个供应商或多个 Agent 框架？

13. 协议治理：比接通更重要

协议一旦进入生产，就要治理。

13.1 版本管理

需要记录：

协议名称
协议版本
工具 schema 版本
Agent Card 版本
MCP Server 版本
前端事件版本
兼容范围
废弃计划

13.2 权限和审批

建议把工具按风险分层：

风险	示例	策略
低风险只读	查询公开文档	可自动执行
中风险只读	查询客户订单	需要用户身份和租户校验
低风险写入	创建草稿、生成报告	可执行但要审计
高风险写入	退款、发邮件、删数据、发布	必须审批

13.3 可观测性

至少记录：

谁发起任务
用了哪个 Agent
调了哪个工具或远程 Agent
参数是什么
返回结果是什么
是否触发审批
是否失败、重试、取消
耗时和成本

13.4 回归测试

协议升级后要测：

工具参数是否仍合法
Agent Card 是否仍能被发现
流式事件是否兼容前端
错误码是否仍可处理
权限和审批是否仍生效
旧客户端是否还能工作

14. 常见误区

误区 1：有了 MCP 就不需要 Function Calling

不对。

Function Calling 是模型 API 层能力，MCP 是工具和资源接入协议。很多系统会同时使用。

误区 2：A2A 可以替代 MCP

不对。

A2A 连接 Agent，MCP 连接工具和数据。A2A 官方也明确强调二者互补。

误区 3：OpenAPI 文档可以直接给模型当工具

多数情况下不建议。

原始业务 API 往往太复杂，需要包装成 Agent 友好的工具。

误区 4：协议解决安全问题

协议只定义交互边界，不自动提供完整安全。

安全仍要靠：

身份认证
权限控制
用户确认
工具沙箱
审计日志
回滚机制

误区 5：一开始就追求全协议架构

小项目先跑通最小闭环更重要。

如果一开始就引入 MCP、A2A、AG-UI、Realtime，复杂度可能超过收益。

15. 一个完整落地案例：企业客服 Agent

假设你要做一个企业客服 Agent 工作台。

15.1 最小版本

text

用户问题
  -> 模型
  -> Structured Outputs 输出分类和风险等级
  -> 人工客服查看结果

协议重点：

Structured Outputs

15.2 接入业务系统

text

用户问题
  -> 模型判断要查订单
  -> Function Calling 调 get_order_status
  -> 返回答案

协议重点：

Function Calling
JSON Schema
REST / OpenAPI 适配层

15.3 工具标准化复用

text

客服 Agent
  -> MCP Server
  -> 订单系统 / 工单系统 / 知识库 / CRM

协议重点：

MCP tools
MCP resources
工具权限和审计

15.4 多 Agent 协作

text

客服 Agent
  -> A2A 委托 财务 Agent
  -> 财务 Agent 通过 MCP 查账单
  -> 财务 Agent 返回结果

协议重点：

A2A Agent Card
Task
Streaming
Artifact

15.5 前端工作台体验

text

客服工作台
  -> AG-UI
  -> 展示 Agent 步骤、工具状态、审批按钮、转人工入口

协议重点：

AG-UI events
状态同步
中断和恢复
人工审批

15.6 语音客服版本

text

浏览器 / 呼叫系统
  -> Realtime
  -> 语音输入、转写、语音输出、工具调用

协议重点：

Realtime API
WebRTC / WebSocket / SIP
工具调用期间的等待话术
安全身份标识

16. 学习顺序

推荐学习路线：

Structured Outputs：先把输出结构稳定下来。
Function Calling：理解模型如何请求应用执行动作。
MCP：理解工具、资源、Prompt 如何标准化暴露。
A2A：理解 Agent 间任务委托与互操作。
AG-UI：理解 Agent 如何接入真实前端体验。
Realtime：理解语音和低延迟交互。
协议治理：版本、权限、审计、评测、回滚。

17. 检查清单

设计 AI 协议层时，可以用下面清单自查：

是否区分了模型输出、工具调用、工具协议、Agent 协作和前端交互？
是否明确哪些工具是只读，哪些有副作用？
是否为高风险工具设计了审批？
是否记录协议版本和工具 schema 版本？
是否有错误码、重试、取消和超时规则？
是否有审计日志和 trace？
是否能对工具调用、Agent 委托和前端事件做回放？
是否有兼容旧客户端的策略？
是否避免把原始业务 API 直接暴露给模型？
是否有协议升级后的回归测试集？

18. 推荐资源

以下资源在 2026-07-07 检查时可访问。

19. 2026 年最容易漏掉的协议现实

19.1 不要把“工具调用”“连接器”“MCP”混成一层

这三层分别解决不同问题：

Function Calling / Structured Outputs：模型如何稳定表达动作意图与参数
Connectors / Remote MCP：模型如何获得对外部服务的新能力
业务服务适配层：你的 CRM、工单、权限、审计系统如何被包装成 Agent 可安全调用的能力

如果把三层混在一起，后面通常会出现 schema 难治理、权限难收口、审批难插入的问题。

19.2 协议一旦进入生产，就必须绑定审批、租户和审计

OpenAI 的 MCP and Connectors 指南已经明确把“自动允许”与“显式审批”区分开来。企业里更要继续往前走一步：

哪些协议动作允许自动执行
哪些动作必须带用户身份与租户上下文
哪些动作必须进入人工审批
哪些动作必须保留可回放审计记录

协议不是单纯“打通连接”，而是把风险边界显式化。

19.3 前端协议要把“事件流”当一等公民

AG-UI 的重点不是做一个聊天 UI，而是把状态、意图、用户交互、流式输出、人工接管这些事件标准化。真正的企业工作台通常需要：

工具执行中状态
等待审批状态
可中断与可恢复状态
人工接管入口
多模态附件和引用证据

如果还用一次请求一次响应的 REST 心智去做 Agent 前端，后面 UI 和运行时一定会撕裂。

19.4 协议治理比接通更难，但也更值钱

真正让系统稳定下来的，不是“终于接上 MCP / A2A / AG-UI”，而是：

schema 版本管理
兼容性回归测试
超时、取消、重试、幂等规则
工具与 Agent 能力画像
trace、eval 和事故复盘

协议一旦成为团队共用边界，这些治理项就必须前置。

20. 企业落地最小闭环

如果现在要在企业里把 AI 协议落地到能上线，建议先收敛到这个最小闭环：

底层业务系统继续保持 REST / GraphQL / gRPC / SQL 等传统接口，不要直接把原始业务 API 裸暴露给模型。
在中间做一层面向 Agent 的工具适配，把高风险写操作和低风险读操作拆开。
对模型输出层使用 Structured Outputs 或严格 schema 的 Function Calling，让参数可验、结果可审。
当工具需要跨多个 Agent 或多个客户端复用时，再抽成 MCP server；当要跨团队或跨框架协作时，再引入 A2A。
如果是工作台或 Copilot 产品，再补 AG-UI 的事件流；如果是语音和实时交互，再补 Realtime / WebRTC / WebSocket / SIP。
最后把审批、租户、trace、eval、回归测试和回滚策略补齐。

这条路径的关键不是一次把协议上齐，而是始终让协议层比业务复杂度慢半拍，但比风险暴露早半步。

21. 最后总结

AI 协议可以按连接方向理解：

模型输出：Structured Outputs
模型到函数：Function Calling
Agent 到工具和数据：MCP
Agent 到 Agent：A2A / ACP
Agent 到用户界面：AG-UI
实时语音和低延迟交互：Realtime / WebRTC / WebSocket / SIP
业务系统底层接口：REST / OpenAPI / GraphQL / gRPC

真正做工程时，最稳的策略不是追热点协议，而是先判断：

当前系统缺的是哪一层标准化？

缺哪一层，就补哪一层。

10. AI协议生态与互操作 ​

1. 为什么需要专门学习 AI 协议 ​

2. AI 协议地图 ​

3. 一张图理解 MCP、A2A、AG-UI ​

4. MCP：Agent 到工具与数据的协议 ​

4.1 MCP 解决什么问题 ​

4.2 MCP 的核心角色 ​

4.3 MCP 的核心能力 ​

4.4 MCP 适合什么时候用 ​

4.5 MCP 的安全要点 ​

5. Function Calling：模型到应用函数的协议 ​

5.1 Function Calling 的基本流程 ​

5.2 Function Calling 和 MCP 的区别 ​

5.3 工具 schema 的设计原则 ​

6. Structured Outputs：模型输出结构协议 ​

6.1 Structured Outputs 和 Function Calling 怎么选 ​

6.2 JSON Schema 设计建议 ​

7. A2A：Agent 到 Agent 的协议 ​

7.1 A2A 解决什么问题 ​

7.2 A2A 的核心概念 ​

7.3 A2A 和 MCP 的关系 ​

7.4 A2A 不是什么 ​

8. ACP：Agent Communication Protocol ​

8.1 ACP 的特点 ​

8.2 ACP 和 A2A 怎么理解 ​

8.3 企业里什么时候会关注 ACP ​

9. AG-UI：Agent 到用户界面的协议 ​

9.1 为什么传统 REST 不够 ​

9.2 AG-UI 适合什么场景 ​

9.3 AG-UI 和 A2A、MCP 的关系 ​

10. Realtime：实时语音和低延迟交互协议 ​

10.1 连接方式怎么选 ​

10.2 Realtime 和其他协议怎么配合 ​

11. OpenAPI、REST、GraphQL、gRPC 仍然重要 ​

11.1 一个推荐分层 ​

11.2 OpenAPI 和 AI 工具的关系 ​

12. 企业 AI 协议选型建议 ​

12.1 从简单到复杂的路线 ​

12.2 按场景选择 ​

12.3 选型时最该问的问题 ​

13. 协议治理：比接通更重要 ​

13.1 版本管理 ​

13.2 权限和审批 ​

13.3 可观测性 ​

13.4 回归测试 ​

14. 常见误区 ​

误区 1：有了 MCP 就不需要 Function Calling ​

误区 2：A2A 可以替代 MCP ​

误区 3：OpenAPI 文档可以直接给模型当工具 ​

误区 4：协议解决安全问题 ​

误区 5：一开始就追求全协议架构 ​

15. 一个完整落地案例：企业客服 Agent ​

15.1 最小版本 ​

15.2 接入业务系统 ​

15.3 工具标准化复用 ​

15.4 多 Agent 协作 ​

15.5 前端工作台体验 ​

15.6 语音客服版本 ​

16. 学习顺序 ​

17. 检查清单 ​

18. 推荐资源 ​

MCP ​

Function Calling 与 Structured Outputs ​

A2A / ACP / AG-UI ​

Realtime ​

19. 2026 年最容易漏掉的协议现实 ​

19.1 不要把“工具调用”“连接器”“MCP”混成一层 ​

19.2 协议一旦进入生产，就必须绑定审批、租户和审计 ​

19.3 前端协议要把“事件流”当一等公民 ​

19.4 协议治理比接通更难，但也更值钱 ​

20. 企业落地最小闭环 ​

21. 最后总结 ​

10. AI协议生态与互操作

1. 为什么需要专门学习 AI 协议

2. AI 协议地图

3. 一张图理解 MCP、A2A、AG-UI

4. MCP：Agent 到工具与数据的协议

4.1 MCP 解决什么问题

4.2 MCP 的核心角色

4.3 MCP 的核心能力

4.4 MCP 适合什么时候用

4.5 MCP 的安全要点

5. Function Calling：模型到应用函数的协议

5.1 Function Calling 的基本流程

5.2 Function Calling 和 MCP 的区别

5.3 工具 schema 的设计原则

6. Structured Outputs：模型输出结构协议

6.1 Structured Outputs 和 Function Calling 怎么选

6.2 JSON Schema 设计建议

7. A2A：Agent 到 Agent 的协议

7.1 A2A 解决什么问题

7.2 A2A 的核心概念

7.3 A2A 和 MCP 的关系

7.4 A2A 不是什么

8. ACP：Agent Communication Protocol

8.1 ACP 的特点

8.2 ACP 和 A2A 怎么理解

8.3 企业里什么时候会关注 ACP

9. AG-UI：Agent 到用户界面的协议

9.1 为什么传统 REST 不够

9.2 AG-UI 适合什么场景

9.3 AG-UI 和 A2A、MCP 的关系

10. Realtime：实时语音和低延迟交互协议

10.1 连接方式怎么选

10.2 Realtime 和其他协议怎么配合

11. OpenAPI、REST、GraphQL、gRPC 仍然重要

11.1 一个推荐分层

11.2 OpenAPI 和 AI 工具的关系

12. 企业 AI 协议选型建议

12.1 从简单到复杂的路线

12.2 按场景选择

12.3 选型时最该问的问题

13. 协议治理：比接通更重要

13.1 版本管理

13.2 权限和审批

13.3 可观测性

13.4 回归测试

14. 常见误区

误区 1：有了 MCP 就不需要 Function Calling

误区 2：A2A 可以替代 MCP

误区 3：OpenAPI 文档可以直接给模型当工具

误区 4：协议解决安全问题

误区 5：一开始就追求全协议架构

15. 一个完整落地案例：企业客服 Agent

15.1 最小版本

15.2 接入业务系统

15.3 工具标准化复用

15.4 多 Agent 协作

15.5 前端工作台体验

15.6 语音客服版本

16. 学习顺序

17. 检查清单

18. 推荐资源

MCP

Function Calling 与 Structured Outputs

A2A / ACP / AG-UI

Realtime

19. 2026 年最容易漏掉的协议现实

19.1 不要把“工具调用”“连接器”“MCP”混成一层

19.2 协议一旦进入生产，就必须绑定审批、租户和审计

19.3 前端协议要把“事件流”当一等公民

19.4 协议治理比接通更难，但也更值钱

20. 企业落地最小闭环

21. 最后总结